速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年
编译：奇安信代码卫士团队
流行的npm 库 netmask 中存在于一个严重的网络漏洞。
数十万应用常常使用 netmask 组件解析 IPv4 地址和 CIDR 块或对它们进行比对。截止目前，该组件的周下载量超过300万次，总下载量超过2.38亿次。另外，约27.8万个 GitHub库有赖于 netmask。
Netmask 组件被曝漏洞意味着，当解析 IP 地址的前导 0 时，由于验证不当，导致 netmask 看到的是不同的 IP 地址。
研究员 Victor Viale、Sick Codes、Nick Sahler、Kelly Kaoudis 和 John Jackson 披露了热门库 netmask 中的这个漏洞 (CVE-2021-28918)，它和 netmask 如何处理混合格式的 IP 地址有关，更具体地说，和十进制 IPv4 地址中包含一个前导0时有关。
IP 地址的表示方式多样，包括十六进制和整数，尽管最常见的IPv4 地址以十进制格式表示。例如，BleepingComputer 的 IPv4 地址以十进制方式表示时104.20.59.209，但也可表示为八进制形式 0150.0024.0073.0321。比如，我们得到的某个 IP 地址是十进制格式：127.0.0.1，则人们通常理解为该地址是本地回环地址或本地主机 (localhost)。如果我们给它加一个前缀，那么应用程序应该将 0127.0.0.1 解析为 127.0.0.1还是其它格式？BleepingComputer 在 Chrome 地址栏中输入 0127.0.0.1/ 中，浏览器将其视为八进制格式的 IP 地址。
按下 enter 或 return 键，该IP地址实际上会更改十进制格式 87.0.0.1，这是多数应用程序应该处理此类有歧义的 IP 地址的方式。
值得特别注意的是，127.0.0.1 并非公开的 IP 地址而是本地回环地址，然而，它具有歧义的表示将其更改为公共 IP 地址，从而造成一个不同的主机。但是在 npm 库 netmask 案例中，任意数量的前导 0 只会被丢弃。IETF 发布的原始声明指出，如果添加前缀 “0”，则部分 IPv4 地址可被解释为八进制。Sahler 和 Viale 表示，“但 netmask 会忽视这一点，它总是将部分考虑为十进制，也就是说如果我们试图验证某个 IP 地址是否属于某个范围，IPv4 地址的八进制表示将是错误的。”
乍一看，该 bug 似乎并非大问题，但攻击者能够影响应用程序解析的 IP 地址输入，则该 bug 可能引发多种漏洞，如服务器端请求伪造 (SSRF) 绕过、远程文件包含 (RFI) 等等不一而足。
研究人员举了一些列子进行说明。比如，“有人运行节点服务器清理入站请求或查询参数，该入站请求或查询参数可能用于进一步连接、提取资源等的 URI。攻击者构造一个 IP 地址，在老旧版本的前缀为0的 JavaScript 表示中，其中某些或全部八位位组都以8为基数。比如这种情况可用于 SSRF，通过传递 0177.0.0.01 强制服务器连接到127.0.0.1。以十进制表示的127就是以8为基数的177。如果某系统暴露webhook 并通过 netmask 检查验证用户的 URL，则该系统易受 SSRF 攻击。
另外，该 bug 可被用于实现远程文件包含，鉴于netmask 将所有 IPv4 部分（八进制）转换为十进制格式的方法，攻击者构造了一个看似为 netmask 私有的 IP 地址，但实际上其它组件将其评估为公开地址。
2018年，热门软件项目curl 也被指存在相似缺陷。当处理八进制的 IPv4 地址为十进制格式时，运行 “curl –v 0177.0.0.1“ 使 curl 连接至 177.0.0.1而不是本地回环地址 127.0.0.1。
当时，道德黑客Nicolas Grégoire 也说明了此类缺陷如何可被用于绕过基于 IP 地址的访问控制列表 (ACLs)。他指出，“我经常使用这些会话绕过反 SSRF 黑名单。”多种网络基础设施和安全产品如 Web Application Firewalls 均依靠 netmask 过滤出现在阻止列表和允许列表中的 IP 地址。这也意味着这类缺陷如未得到检查，则可导致外围安全控制中出现严重失误。
此前，Sick Codes、Jackson和 Sahler 曾在 private-ip 程序包中找到一个相似缺陷，而结果显示即使是在今天，该程序包也在使用 netmask 作为依赖关系。Jackson 指出，这个新发现的 netmask 漏洞可导致数千项目易受 SSRF 绕过有影响，“Netmask 每周的下载量达到数百万次，使其造成的影响巨大，它是一个严重的软件供应链漏洞。Private-ip 漏洞当时的严重程度达到9.8，但每周的下载量仅为17.5万次。”
安全研究员的主要担忧是，使用 netmask 解析 IP 地址的很多项目可能错误地认为自己免受 SSRF 漏洞攻击。
研究员负责任地报告该漏洞后，netmask 的开发者 Olivier Poitrey 在 GitHub sha能够推出了一系列修复方案以及相关测试案例，即验证前缀为 0 的 IPv4 八位位组被当作八进制而非十进制数字 (number) 处理。
该漏洞的修复方案已发布在netmask 2.0.0版本中 (下载地址为https://www.npmjs.com/package/netmask)。
当问到该漏洞的严重程度时，这名开发者表示取决于对“严重”级别的定义，“取决于你如何定义‘严重’以及你如何使用该库。它并非缓冲区溢出或远程执行类漏洞。我无法 DoS 你的 app 但如果某 IP 访问使用该库，则可削弱你的 ACL。虽然还未想到它的利用场景，但ACL多数基于从 IP 栈获悉的 IP 地址，而它们将永远不会使用这种易受攻击的格式。”
建议 netmask 用户升级至已修复版本2.0.0。
尽管尚未证实 Perl 组件 Net::Netmask是否也受此缺陷影响，但建议使用 Perl 版本的开发人员应确保在将其传递为 netmask 的输入时，应用程序已得到清理且IP地址已规范化。
漏洞详情可见博客全文：
https://sick.codes/universal-netmask-npm-package-used-by-270000-projects-vulnerable-to-octal-input-data-server-side-request-forgery-remote-file-inclusion-local-file-inclusion-and-more-cve-2021-28918/
开源项目已成为当今软件开发的核心基础设施，如GitHub 于近期发布博客文章指出，“ 项目常常会使用数百个开源依赖关系（每个仓库平均使用203个开源依赖关系）”。npm 开源库的组件netmask可能出现在软件的整个生命周期如开发、交付、运行等，是数量庞大的开源项目的依赖关系。GitHub 还指出，如果依赖关系中出现漏洞，即使目前不可被利用，但代码库内部或外部做出修改后可能会使我们在未来遭受攻击。未修复软件仍然是目前软件供应链攻击事件的罪魁祸首。在现代软件供应链攻击场景下，由于开源组件 netmask 的使用人数众多，而其中的漏洞已存在九年之久，它一旦遭利用，就会使攻击影响力放大，从而造成不可预估的后果。
企业如何在软件供应链场景下缓解此类依赖关系漏洞？企业应梳理开源组件资产，形成软件物料清单，了解环境中的依赖关系来源并定期检查依赖关系中的漏洞；制定相应的开源软件制度，规范开源组件/软件的引入流程，管理好依赖关系并预防新漏洞的产生；了解并管理企业所使用依赖关系的风险，及时修复漏洞，做好开源安全事件响应工作，防止依赖关系成为软件供应链攻击的薄弱链条。
目前，奇安信开源卫士已支持对npm库漏洞的检测。
开通奇安信开源卫士 (https://oss.qianxin.com) 账号，我们帮您全面排查 Linux 主机环境和应用软件资产是否受开源软件漏洞影响。
详解恶意软件 XcodeSpy 如何针对 iOS 开发人员展开供应链攻击
找到软件供应链的薄弱链条
GitHub谈软件供应链安全及其重要性
https://www.bleepingcomputer.com/news/security/critical-netmask-networking-bug-impacts-thousands-of-applications/
题图：Pixabay License
本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。